DevSecOps_03_SAST의 동작 원리와 AST(추상 구문 트리)

정적 애플리케이션 보안 테스팅(SAST)은 코드를 실행하지 않고 소스 코드 자체를 분석하여 취약점을 찾는다. 겉보기에는 Ctrl+F와 같은 문자열 검색과 비슷해 보일 수 있지만, 현대적인 SAST 도구는 훨씬 정교한 문맥 인식(Semantic Analysis) 기술을 기반으로 한다. 단순한 grep과 전문 SAST 도구는 어떤 논리적 차이가 있는지 분석한다.

1. 텍스트 매칭의 한계

가장 단순한 접근법은 위험한 함수나 변수를 문자열로 찾는 것이다. 예를 들어, eval() 함수는 보안상 위험하므로 이를 검색한다고 가정해보자.

# 단순 검색으로 탐지 가능 (True Positive)
eval(user_input)

# 주석인데도 탐지됨 (False Positive)
# Don't use eval() here

# 변수명이 같아서 탐지됨 (False Positive)
eval_score = 100

단순 텍스트 매칭은 주석, 문자열 리터럴, 변수명 등을 코드로 오인하여 수많은 오탐(False Positive)을 만들어낸다. 오탐이 많아지면 개발자는 보안 경고를 끄게 된다.

2. AST: 코드를 구조로 이해하기

이 문제를 해결하기 위해 SAST는 코드를 단순한 텍스트가 아닌, 추상 구문 트리(Abstract Syntax Tree, AST)라는 트리 구조로 변환하여 분석한다. 파서(Parser)가 코드를 읽어 문법적 구조를 이해하는 것이다.

AST를 사용하면 다음과 같은 구분이 가능해진다.

• eval(input)은 함수 호출(Call Expression) 노드이다. -> 탐지 대상
• # eval은 주석(Comment) 노드이다. -> 무시
• eval_score는 변수 선언(Assignment) 노드이다. -> 무시

2.1. 의미론적 패턴 매칭(Semantic Matching)

Semgrep과 같은 최신 도구는 이 AST 구조 위에서 패턴 매칭을 수행한다.

patterns:
  - pattern: eval($X)

이 규칙은 텍스트 줄을 찾는 것이 아니라, "함수 이름이 eval이고, 인자 $X를 받는 함수 호출 노드"를 트리에서 찾는다. 띄어쓰기나 줄바꿈이 달라도 구조가 같으면 정확히 탐지한다.

3. Taint Analysis (오염 분석)

AST만으로는 부족한 경우가 있다. 위험한 함수를 쓰더라도, 그 안에 들어가는 데이터가 안전하다면 취약점이 아니기 때문이다.

# Case A: 안전함 (상수 전달)
eval("1 + 1")

# Case B: 위험함 (사용자 입력 전달)
eval(request.GET['cmd'])

이를 구별하기 위해 Taint Analysis 기법을 사용한다.
외부 입력(Source)이 들어와서, 검증 없이 위험한 함수(Sink)로 흘러들어가는 경로(Data Flow)를 추적하는 것이다. 이 논리가 적용되어야만 비로소 "진짜 위험한 코드"만을 선별해낼 수 있다.